• 菜雞行為：把程式碼交出去當成已經交付
• STAR 階段：S (Situation)
• 本篇定位：呈現功能在作者手上會動，交給別人後卻缺少必要知識。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

上一組故事收在 Day 21｜我用 Log、狀態和測試證據把完成條件釘住。這一組的學生味：程式碼交出去，就當成交付完成。本篇只停在情境，任務定義留給 Day 23。

功能會動、測試也過，接手的人卻開不起來

以下情境來自我概括後的工作經驗，細節放進虛構的「粉鳥工單服務」。我做完工單逾期提醒的排程功能，程式碼合併進主線，測試也通過。之後功能交給另一位開發者維護。對方拿到完整的 repo，排程卻停在原地：環境變數、啟動順序、資料前提，他一樣都不知道。我的訊息視窗成了客服台：問題我都答得出來，答案卻都不在 repo 裡。

[接手者拿到的]          [接手時真正需要的]
 程式碼                  程式碼
 測試                    環境變數與啟動順序
 合併紀錄                資料前提與已知限制
                         測試方式與回復步驟

兩欄落差，就是留在我腦裡、沒交出去的那截系統。

當時為什麼覺得程式碼在 repo 裡就夠了

我不是故意省略交接。在我的理解裡，程式碼是最誠實的文件：讀程式最準，README 常常過期。這套想法對一種讀者成立：一路跟著開發的我自己。我天天啟動它，環境變數是手指的記憶，啟動順序是肌肉的習慣，便宜到讓我忘了它們存在。

交付的讀者，是一個沒有我的人

漏掉的是讀者設定。交付的讀者是沒跟過開發的人，他要的不是讀懂程式，而是能啟動、能驗證、出事能回復。功能在我手上會動，只證明「作者加系統」這個組合會動；把作者抽走，系統就剩一半。我交出去的是程式碼，不是交付。

卡住的地方就是隱性知識

接手者的每個問題，都指向一筆隱性知識：啟動、資料前提、限制、測試與回復。先看見缺口在哪裡，才談得上哪些值得寫下來；補一疊厚文件不是重點。

今天可以帶走的練習

挑一項正在維護的功能，用《系統脈絡檢核表》假想自己明天不在場，逐項檢查啟動、資料前提與失敗邊界是否有文件。產出是一份缺口清單，驗收是請另一位讀者只看現有文件，指出無法啟動、驗證或回復的地方。功能很小或接手者全程參與時不必填表。

對應工具：《系統脈絡檢核表》。

# 系統脈絡檢核表

用途：交接前確認接手者能否掌握系統的入口、資料與失敗邊界。
使用時機：成果要交給沒有跟過開發過程的人維護時。
不必使用：接手者全程參與開發、口頭確認就足夠時。

| 項目 | 是否清楚 | 待補資訊 |
| --- | --- | --- |
| 啟動方式與環境變數 | 否 | 啟動順序與設定來源 |
| 資料前提與外部相依 | 否 | 依賴哪些狀態欄位與服務 |
| 失敗邊界與回復方式 | 否 | 卡住時從哪裡重跑 |

提醒：只填影響接手的資訊；不放機密、個資與可辨識人物。

下一篇

把腦裡的東西全部寫下來，只會堆出沒人維護的文件山。一次交付至少要包含什麼，Day 23｜一次交付還欠哪些文件、限制和回復方式，會把它定義成真正的任務。